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AFFIDAVIT OF TUAN BUI UNDER 37 C.F.R.S 1.131 


I, Tuan Bui, being duly sworn, hereby state: 

1 I am one of the named inventors of the subject matter claimed in the above- 
identified patent application and am familiar with the inventions disclosed therein, 

- 2 ; . ■:- I conceived of the inventions of claims 1 to 191 in; this country at least "te-carlyasr- 
November 30, 2001, as eviaencea oy a memorandum which I helped draft, a copy of which is 
attached as Exhibit A. 

3. On December 3, 2001, I corresponded with my attorneys regarding the 

preparation and subject matter of the above-identified patent application. 
SBBM BWBBW iMMMBBB WBfflBWBHHHB 

4. On Decemberl4^U0l7^neH^ the preparation and 
subject matter of the above-identified patent application. 

5. I received a draft of the above-identified patent application from my attorneys on 
or about January 3, 2002. 
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6. On January 14, 2001,. I was copied on correspondence from James Martucci, a 
named inventor of the above-identified patent application, to our attorneys regarding the draft 
patent application, 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true and further, I acknowledge 
that willful false statements and the like are punishable by fine or imprisonment, or both, under 
§1001 of Title 18 of the United States Code and may jeopardize the validity of the application or 
any patent issuing thereon. 
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FURTHER AFFIANT SAYETH NOT: 
Signature 

Name; Tuan Bui 

Address: IMUH* q/L65/dn6i,> 6 


Date Signed 


State of j^Z 
County of l^fe 


) 

)SS. 
.) 


On this £ day of , 2007, before me, a notary pub^lff 

and for the aforementioned state and county, personally appeared the person whose name is 
subscribed to the foregoing instrument, and executed the foregoing instrument in my presence 
for the purpose contained therein, by signing his name hereto. 


IN WITNESS WHEREOF, I hereto set my hand and official seal 
My Commission Expires: 


Date: 


my nana ana oraciai seal. 
Notary Public jtf 



OFFJCWLSEAL 
KORIRCAYA 
NOTARY PtfflUC - STATE OF CUNOtS 
MY COMMISSION EXPiRES:06/14/10 
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To: Fran Kowalik, Esq. 

From: Tuan Bui & Jim Martucci 

Subject: Detailed Description of Method to Program a Medical Device in a Network 
Date: November 30, 2001 


This document will describe alternative methods of programming a medical device within a 
computer network structure. 

Background 

The use of medical devices at the patient point of care (POC) has historically been accomplished 
using manual data management processes, (i.e., programming the device to the appropriate 
settings for a specific use, recording the output data and alarm conditions generated during 
routine use of the device on a patient) - via pen and paper data collection. The advent of wired 
computer networks in the early 1960s and the subsequent implementation of computer network 
standards such as Ethernet in the 1970s resulted in the growing use of computers to automate 
manual processes such as described above. However, medical institutions do not typically utilize 
such networks to the extent of including the point of care , i.e., the use of Ethernet at the patient 
bedside occurs is less than 10% in US hospitals (although the network is very commonly wired 
to the nursing station location). Possible reasons for the lack of connection to POC are: 1) the 
completion of the network to the POC in existing hospital facilities was cumbersome and costly 
2) the presence of the wired network at POC may not have been worthwhile until medical 
instruments that can use those networks became available, 3) There are no standard 
communication protocols to enable instruments to easily communicate (although a great deal of 
effort has been focused on IEE 1073 and HL7, for example) and 4) there may be a multiplicity of 
different devices at the POC and these devices need to roam or move with the patient making the 
use of a wired solution difficult. 

Starting in the 1980's the use of wireless computer networks, both proprietary (such as Proxim) 
and open (such as IEEE 802.11 "wireless Ethernet") enabled hospitals to use medical devices on 
patients and connect their input and output data via a wireless technology. This allowed 
hospitals to workaround issues 1-4 above because the network was relatively easy to install, 
devices were becoming available, the standard was Ethernet and the devices could roam. 

Method for Programming Medical Devices, Including Infusion Pumps 

Normally, the data set for programming a medical device, such as an infusion pump, originates 
with the physician order for a drug, which is captured in the database of the hospital pharmacy 
system. There may be exceptions such as emergency situations, or the use of an alternate site 
infusion center, but in the hospital environment, the pharmacy database is the key source of data. 
Today, the transfer of information from various aspect of the patient care, from order entry 
through the pharmacy to the programming of an infusion pump, is done manually: The process 
of generating a prescription label from the pharmacy system is done manually, and the clinician 
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manually programs that prescription data set into an infusion pump and manually captures the 
delivery history from the infusion pump to a medication administration record. 

This invention proposes to program the medical device directly from the pharmacy database 
using a wireless computer network, including handheld devices at the POC to direct the process. 
It is integrated with a bar coding system to automatically verify the correct patient and 
prescription information as outlined below. The following is an outline: 

• Option 1: Set Infusion Parameters Automatically 

• Scan patient 

• Scan bag 

• Scan pump 

• If the patient bag and pump match, the system automatically uploads infusion parameters from 
pharmacy system (CIS Database in Figure 1 below) to infusion pump. 

• Option 2: Alternative Scheme to Set Infusion Parameters 
Manually 

• Nurse programs the pump manually. 

• Prescription data is transmitted to the network from the pump via the wireless network 

• Prescription data is checked against the order in the database 

• CIS database sends a real-time warning to the PDA if there was a wrong entry 

• System provides real-time tracking of flow rate and operating conditions of infusion pump. 
Alarm conditions are communicated to PDA from CIS database based on assigned patients. 

• Additional Feature of Tracking Clinical Documentation for 
Infusion Flow Rate Changes 

• Nurse scans bag. 

• Nurse enters flow rate changes in the PDA (for mandatory documentation. 

• Information is automatically sent to the CIS database in pharmacy for production scheduling 
updates. 

The following is an outline of the clinical verifications that occur as a result of these steps. 

• Scan pump barcode 

• Identifies pump 

• Scan patient barcode 

• Verify RIGHT patient 

• Scan bag barcode 

• Verify RIGHT bag 

• Verify in real-time whether order is still active 

• Verify RIGHT start time 

• Verify RIGHT bag sequence 

• Clinical alerts, pre/post-admin actions 
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Figure I: Typical System Configuration for Invention 


ADE 

(Adverse Drug Event 
Database) " 




Local Area Network 


Wireless IEEE 802.11 
Communication 


• null 


Wireless Bar Code Reading 
(infrared or imager) or RFID 
Reading Process 


The following are potential inventive claims to support the invention. These proposed claims 
outline some alternatives that may not be described in detail above, but should be self --evident 
based on the background description. 

CIS Server directly programs medical device 

1) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

• Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 

• Inputting patient identification data from a first source into the second processor. 

• Inputting medication identification data from a second source into the second processor. 
Medication data include patient identification data. 

• Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data. 
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• Communicating the medication data and the patient identification data from the second 
processor to the first processor. 

• Comparing the communicated patient identification data with the stored data in the first 
processor (using the first processor?). 

• Communicating the medical device operating parameters to the medical device from the 
first processor and programming the medical device according to the communicated 
operating parameters. 

2) The method of claim 1 further comprising the steps of communicating the medical device 
operating parameters to the second processor. 

CIS server directly programs medical device and user confirms 

3) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

• Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 

• Inputting patient identification data from a first source into the second processor. 

• Inputting medication identification data from a second source into the second processor. 
Medication data include patient identification data. 

• Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data 

• Communicating the medication data and the patient identification data from the second 
processor to the first processor 

• Comparing the communicated patient identification data with the stored data in the first 
processor (using the first processor?). 

• Communicating the medical device operating parameters to the second processor. 

• Confirmation of the medical device operating parameters on the second processor. 

• Communicating the confirmation to the first processor. 

• Communicating the confirmed medical treatment data from the first processor to the 
medical device and programming the medical device according to the communicated 
operating parameters 

4) The method of claim 3 further comprising the steps of: 
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Communicating from the medical device to the second processor to acknowledge the completion 
of the programming of the medical device according to the communicated operating parameters 


POC device programs medical device from bar code and CIS server confirms 

5) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 

Inputting patient identification data from a first source into the second processor. 

Inputting medication identification data and medical device operating parameters from a 
second source (via bar code, or RFTD, or magnetic stripe, or OCR) into the second 
processor. Medication data include patient identification data. 

Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data 

Communicating the medication data, the medical device operating parameters and the 
patient identification data from the second processor to the first processor. 

Comparing the communicated patient identification and medical device operating 
parameters data with the stored data in the first processor to confirm its' continued 
validity for patient care. 

(Optional) Communicating the medical device operating parameters to the second 
processor. 

(Optional) Confirmation of the medical device operating parameters on the second 
processor. 

(Optional) Communicating the confirmation to the first processor. 

Communicating the confirmed medical treatment data from the first processor to the 
medical device and programming the medical device according to the confirmed 
operating parameters 

Medical device is POC device- no second processor 

6) A method to control the delivery of medical treatment to a patient from a medical device, 
comprising of: 

• Storing the medical treatment data in the first processor (medical treatment data = patient 
identification data, medication data, medical device operating parameters) 
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• Inputting patient identification data from a first source directly into the medical device 
(via bar code, or RFID, or magnetic stripe, or OCR). 

• Inputting medication identification data and medical device operating parameters from a 
second source (via bar code, or RFID, or magnetic stripe, or OCR) directly into the 
medical device. Medication data include patient identification data. 

• Verifying that the patient identification data from the first source matches with the patient 
identification data from the medication data 

• Communicating the medication data, the medical device operating parameters and the 
patient identification data from the medical device to the first processor. 

• Comparing the communicated patient identification and medical device operating 
parameters data with the stored data in the first processor to confirm its' continued 
validity for patient care. 

• (Optional) Communicating the medical device operating parameters to the medical 
device. 

• (Optional) Confirmation of the medical device operating parameters on the medical 
device. 

• (Optional) Communicating the confirmation to the first processor. 

• Communicating the confirmed medical treatment data from the first processor to the 
medical device and programming the medical device according to the confirmed 
operating parameters 
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